\section{IPsec and the BEET-Mode} \label{sec:ipsec}
The IP Security, or short IPsec is a set of protocols developed by the ITEF
to enhance the security of the Internet Protocol at IP layer. The IPsec
consists of many RFCs which define protocols in different aspects. 
We discuss in
the following sections IPsec in the context of HIP.

\subsection{IPsec and ESP}
Since the IPsec provides security at IP layer, it is transparent for all
applications which use IP. IPsec provides two kinds of security mechanisms, the
Authentication Header (AH) which provides authentication of the sender of
the data, but no encryption, and the Encapsulated Security Payload (ESP)
which provides authentication of the sender AND encryption of the payload.
In the HIP architecture \cite{hip_arch}, the ESP is the only defined method to
transport data packets.
\subsubsection{Security Policy and Security Association}
We introduce in the following some background information and
fundamental concepts for  IPsec in HIP context.

A \emph{Security Policy} is a rule implemented in IPsec which decides how
the IPsec is applied to IP datagrams. For example, on receiving IP datagram,
it can make decision on what kind of IP packets can bypass the IPsec
processing, and what kind of packets should be processed by IPsec. The
security policies are stored in a \emph{Security Policy Database} (SPD).

According to the SPD, if a secure connection should be established, the
both peers will establish \emph{Security Associations} (SA). A SA is a
unidirectional channel which provides security features. Since it is
unidirectional, it gives us the possibility to provide different level of
security for inbound and outbound traffic. The SAs are stored in a
\emph{Security Association Database} (SAD). A security association is
uniquely identified by a triple consisting of the Security Parameter Index
(SPI), the
destination IP address and the mechanism of the security (AH or ESP). The
SPI, normally a 32-bit integer number,  is a local identifier 
placed in the AH or ESP datagrams in plaintex to 
help the kernel to select the right SA which is responsible for the
connection. 

It is very important to manage these databases, otherwise it will be
difficult to multiplex and demultiplex the IPsec traffic. HIP for example, creates
and updates the SAs during the Base Exchange and the Update process.

\subsubsection{ESP Modes}
The Encapsulating Security Payload (ESP) (RFC 2406 \cite{rfc2406}) protocol
is a key protocol in the IPsec architecture. The ESP provides 
authentication and 
confidentiality
and places the encrypted data in the new IPsec packets. 

Depending on the requirements of a user, the authentication and
confidentiality of the data can take place only at the transport layer (TCP,
UDP etc.) to provide a point-to-point security tunnel, or it can affect
the whole IP packet including the IP header. This mechanism is often used
to build a gateway-to-gateway secure tunnel of two networks over the
insecure channel like the Internet. A third transport mode is proposed by
Nikander and Melen \cite{ipsec_beet}, the \emph{Bound End to End Tunnel
Mode (BEET)} makes the implementation of HIP easier. 

In the \emph{transport mode}, the ESP datagram is inserted directly after
the IP header. The original IP payload is encrypted and authenticated by ESP, but the IP
address remains intact and is not authenticated. As described earlier, this mode is primarily used to
establish a secure point-to-point channel.

In the \emph{tunnel mode}, the whole IP datagram including the IP header is
protected by the ESP. A new IP header, known as the \emph{Outer IP header}
is
needed. The IP addresses in the outer IP header
are normally the IP addresses of the gateway servers. Once the IP packet is
received at the other end of the gateway, it will be decapsulated and the
packets are sent to other parts of the network.

\begin{figure}[htb]
 \centering
 \includegraphics[width = 14cm]{pics/ipsec}
 \caption{The different ESP modes and their header structures}
 \label{img:ipsec}
\end{figure}

The \emph{Bound End to End Tunnel mode (BEET)} ESP of IPsec uses a transport
mode packet form, but provides limited semantics of the tunnel mode, i.e. 
it archives partly
the effect of tunnel mode without tunnelling overhead. 

The IPsec BEET mode requires two kinds of IP addresses. The \emph{inner
address} which is seen by the application and then replaced by the gateway
through an
\emph{outer address}. The  packet is sent to the outer address.
To achieve this, the gateway must maintain a mapping between the SPI and
the destination address.

Figure \ref{img:ipsec} illustrates the fields protected by
different ESP modes.

\subsection{HIP and the IPsec BEET mode}
The BEET mode IPsec supports HIP by defining the inner address as the HIT
and the outer address as the endpoint destination address. The
IPsec BEET mode kernel module plays the role as gateway. During the Base 
Exchange, 
the mappings between HIT and destination IP address are collected.
The IP addresses of the ESP traffic will be replaced from HIT to
destination IP address by the BEET mode ESP module, or 
an interfamily transformation is performed if the HIT and the IP address
are not in the same address family. After that, the new IP packet is sent
over the normal network (IPv6 or IPv4). 

By using the IPsec BEET mode ESP, it was possible to move the HIP protocol 
instance from
kernel space to userspace in order to make the deployment of HIP
easier.
